home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.20030409-20031118 / 000021_toralf-delete-…@procaptura.com_Mon Apr 28 09:21:49 EDT 2003.msg < prev    next >
Text File  |  2003-11-18  |  4KB  |  78 lines
  1. Article: 14237 of comp.protocols.kermit.misc
  2. Path: newsmaster.cc.columbia.edu!phl-feed.news.verio.net!iad-feed.news.verio.net!iad-peer.news.verio.net!news.verio.net!newsfeed.icl.net!newsfeed.fjserv.net!skynet.be!skynet.be!news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed1.e.nsc.no!nsc.no!nextra.com!news2.e.nsc.no.POSTED!53ab2750!not-for-mail
  3. From: Toralf Lund <toralf-delete-this@procaptura.com>
  4. Subject: Re: Communication protocol for direct serial link (null-modem or similar)?
  5. Newsgroups: comp.protocols.misc,comp.protocols.kermit.misc
  6. Organization: ProCaptura AS
  7. References: <3R6qa.6946$b71.104830@news4.e.nsc.no> <b8bdvn$iun$1@watsol.cc.columbia.edu>
  8. User-Agent: Pan/0.11.4 (Unix)
  9. Mime-Version: 1.0
  10. Content-Type: text/plain; charset=iso-8859-1
  11. Content-Transfer-Encoding: 8bit
  12. X-Comment-To: "Frank da Cruz" <fdc@columbia.edu>
  13. Lines: 56
  14. Message-ID: <n05ra.7849$8g5.113401@news2.e.nsc.no>
  15. NNTP-Posting-Host: 193.214.130.21
  16. X-Complaints-To: news-abuse@telenor.net
  17. NNTP-Posting-Date: Mon, 28 Apr 2003 09:47:31 MEST
  18. X-Trace: news2.ulv.nextra.no 1051516051 193.214.130.21
  19. Date: Mon, 28 Apr 2003 09:47:31 +0200
  20. Xref: newsmaster.cc.columbia.edu comp.protocols.misc:9757 comp.protocols.kermit.misc:14237
  21.  
  22. On Fri, 25 Apr 2003 15:42:15 +0200, Frank da Cruz wrote:
  23.  
  24. > In article <3R6qa.6946$b71.104830@news4.e.nsc.no>, Toralf Lund
  25. > <toralf-delete-this@procaptura.com> wrote:
  26. > : I'm looking for a protocol that may be used for simple communication
  27. > : across a direct serial link - RS232 using null-modem cable or similar
  28. > : - between a Linux host and a simple (old) IPC (Intelligent Peripheral
  29. > : Controller) board.
  30. > : 
  31. > : The IPC has no real OS, just a simple, custom kernel, and rather
  32. > : limited development support, so the protocol needs to be simple to
  33. > : implement. Also, the system is really low-end by today's standards -
  34. > : it's has a 12.5Mhz MC68010 CPU and 1Mb RAM - so the runtime must be
  35. > : fairly small and efficient.
  36. > : 
  37. > : The link will be used only to send simple packets ("commands") to the
  38. > : IPC, and status from the IPC back to the Linux system; there will be
  39. > : no file transfers or anything.
  40. > : 
  41. > : Protocols I've considered:
  42. > : - Kermit
  43. > : - AHDLC/LAPB (as utilised e.g. by PPP) - X/Y/Z-modem
  44. > : 
  45. > : What would you people out there recommend choosing? And does anyone
  46. > : know of any good example source code that may help me get started? I'm
  47. > : primarily interested in a nice and isolated implementation of the
  48. > : packet communication itself, i.e. source code without all the
  49. > : additional bits normally found in comms packages, like UI operations,
  50. > : file I/O, modem dial etc., which I don't need (and I don't want them
  51. > : there to confuse everything.)
  52. > : 
  53. > Embedded Kermit is exactly like that, except it's for transferring
  54. > files, not sending simple messages:
  55. > 
  56. >   http://www.columbia.edu/kermit/ek.html
  57. > 
  58. > If you treat a message as a file, then Kermit would be fine.
  59. How would I do that? What does the "file" interface look like?
  60.  
  61. > You'd need
  62. > to adapt E-Kermit to the IPC, but that's what it's designed for.  Then
  63. > use a regular Kermit version on whatever you are connecting to the IPC,
  64. > such as Linux.  The nice thing about Kermit is that you are not
  65. > constrained when picking implementation platforms.  You can switch from
  66. > Linux to Windows to DOS to Solaris, etc, at any time:
  67. > 
  68. >   http://www.columbia.edu/kermit/
  69. > 
  70. > Kermit is also appropriate because it was designed with unreliable
  71. > serial ports in mind, and therefore expects transmission errors and
  72. > recovers from them efficiently.
  73. Yes, that would be the whole point, obviously.
  74.  
  75.  
  76. -- 
  77. - Toralf
  78.